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REMARKS/ARGUMENTS 



In response to the Examiner's final Office Action of July 22, 2008, Applicants will herein 
present their considerations to the Examiner's comments. 

It is noted that in this application claims 21 - 27 are currently under examination. 

Claim 26 has now been amended to show a proper comma after "memory means 1 ' and 
also a word "an" preceding ™ electronic database — . 

It is noted that previous rejections under 35 USC § 1 12 have been withdrawn. 

Examiner cites 35 USC §101 against claims 23 and 24 as they may be construed to be 
software per se (that is to say a program). 



MPEP 2106.01 states computer programs claimed as computer listings per se are 
not physical "things". They are lacking in structural and functional 
interrelationships between the computer program and other elements of a 
computer. 

In this regard Applicants have added certain hardware module items to the claims 
in order to ground them to physical objects. 



The Examiner has rejected the claims 21-25 under 35 USC §103 (a) as unpatentable 
over Krychniak (U. S. Patent 6,192,357) in view of Prabhakaran (U.S. Patent 6,859,758) and 
further in view of Tenorio (U.S. Patent 6,708 f 161). 

• Applicants would traverse these conclusions of Examiner on the basis of using hindsight 
and on the basis of trying to combine completely different system configurations into one which 
would involve undue research, development and experimentation. 

In regard to Applicant's claim 21 Examiner contends Krychniak teaches a system for 
improving performance of a database by determining whether or not to alter the fields of the 
database having entities which hold the set of data values. 

Here the Examiner has cited Krychniak Fig. I, fact table and Fig. 3 for Applicant's claim 
28 clause (iiia). These drawings of Krychniak do not show defining of an additional entity table . 

Examiner considers Applicant's (iiib) and cites Krychniak Fig. 1, fact table, plus 
dimensions 1-3, Fig. 1 and Figs. 2(a) - 2 (c) whereby information defining the conceptual entity 

Docket No: 614-L Page 7 of 16 AWK 



PAGE 10/19 1 RCVD AT 9/22/2008 12:53:18 PM [Eastern Daylight Time] * SVfcUSPTO-EFXRF^ftt * ONIS:2/38300 ' CSID:9493805254 * DURATION (mm-ss):06-10 



09/22/2098 09:54 9493805254 



UNISYS MV LAW DEPT 



PAGE 11/19 



Appl.No. 10/67U59 

Amdt. doted September 22, 2008 

Reply to Final Office Action of July 22 ? 2008 

is obtained by performing a single read operation (where Krychniak column 2 lines 1 1-28 
disclose performing a read operation on the fact table (also Fig. 4). 

However it is noted Krychniak does not expressly teach Applicant's claim 21 step (i) — 
of determining an average read/write ratio of the plurality of data values and also step (ii) 
comparing the average read/write ratio to a predetermined critical read/write ratio. 

Then Examiner brings in the case of Prabhakaran by maintaining he teaches Applicant's 
claim 21 step (i) of — determining an average read/write ratio at (column 5 lines 55 - 65) and 
(column 6 lines 27 - 29) to estimate performance of a database. 

Examiner says Prabhakaran teaches Applicant's claim 21 clause (ii) - comparing 
the average read/write (steps 330 column 5 lines 66 - 67 and column 6 lines 31 - 
47) to "suggest" comparing the average read/write ratio with other read/write 
ratios. And Prabhakaran has no teaching of a critical read/write ratio. 

Here it should be noted that a "suggestion" is not enough to teach 
and indicate a useful feature. 
Examiner says it would be obvious to use the average read/write ratio from Prabhakaran 
because — this would give Krychniak the benefit of an efficient threshold on which to determine 
a specific access method (Krychniak Fig. 4 and claim 3). 

But as indicated by the Examiner, Krychniak and Prabhakaran fail to teach — in 
Applicant's step (ii) — a predetermined critical read/write ratio. 

At this point the Examiner cites the Tenorio reference and says Tenorio teaches a critical 
read/write ratio (column 1 7 lines 55 - 59 and Fig. 6) for comparing implementations (indexed or 
not indexed) for the database. 

Examiner maintains it would be obvious for one of ordinary skill to combine the cited 
teachings together with Tenorio where this would have given both Krychniak and Prabhakaran — 
a ratio for each to compare performance of access, and the benefit of choosing an efficient 
database implementation. Examiner also says that the desired ratio of Prabhakaran to the 
Tenorio critical read/write ratio would give Krychniak a basis on which to define a fact table. 

Applicants would traverse these considerations and indicate that these are helpful 
idealistic and hopeful features which, it would appear, the Examiner is trying to impute as 
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advantageous with these three references combined, but Examiner is making use of hindsight by 
combi ning other extraneous features to design a system which takes in Applicant's use of a 
critical read/write function. 

Note that the Examiner stated this could have been done (like the argument in 
Applicant's step iii) — where the average read/write ratio is greater than the critical read/write 
ratio — and the Examiner states the desired average ratio is suggested (?) to be greater than the 
critical ratio for the benefit of choosing an efficient database implementation. Applicants do not 
interpret this suggestion as a definite teaching. 

It would appear to Applicant that this is reasonable speculation as to what could be done 
or what would hope to be done or how an engineering group would get together and redesign the 
entire system with hindsight. 

But this is not easily practicable where these useful extraneous ideas could just be 
plucked and strung together into one workable unified configuration. 

Even after the case of KSR v. Teleflex there must be a clear and forthright explanation as 
to why and how extraneous features should be picked from various references and put together to 
form a new combination. 

So in this regard Applicants would respectfully state that they consider it an unwarranted 
use of hindsight on the part of the Examiner to combine these references especially since there is 
a considerable difference factor involved where each cited case handles a different problem. 

In regard to Examiner's objections under 35 USC §101 as the claims being construed 
merely as software per se — Applicants have amended the claims to indicate the physical 
attributes involved which are used to implement the computer program. As such, it will be seen 
that the claims show "acts" being performed. Thus with the presently amended claims, it will be 
understood from the language that there are also physical modules and also physical elements 
involved. 

Turning to the substantive objections taken to the claims under § 103(a), Applicant 
respectfully disagrees with the Examiner's assertion that the claimed invention is obvious in light 
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of Krychniak when combined with both Prabhakaran ct al and Tenorio- Applicants would 

traverse the applicability of Section 103(a). 

Applicant submits as a first point T that the Examiner is still incorrectly equating certain 
features present within the cited reference documents to other features of the claimed 
invention (and thus incorrectly coming to the conclusion that the cited reference 
documents, in combination, to teach of each and every feature of the claimed invention). 
The references do not teach each and every feature of Applicant's configuration. For 
example, in amended claim 27 clause (iia) and (iib) is not taught. 

Moreover, Applicant contends as a second point II that there is insufficient teaching, 
suggestion and motivation for the Examiner to combine each of the cited references in 
order to maintain such an obviousness objection . 

L With regards to the first point, and having specific regard to Krychniak^ Applicants 
again submit that there is no explicit teaching anywhere in Krychniak of defining an additional 
entity table which stores an aggregation of data values (i.e. not merely pointers or keys to other 
tables positioned within the database structure) representing an aggregation of at least one of the 
plurality of conceptual entities (i.e. entities pre-existing within the database). 

After reading the Krychniak disclosure Btrmcrous times, the Applicant cannot understand 
how the "Field" table taught in Krychniak can be equated to the " additional table" of the 
presently claimed invention. 

The Field table taught in Krychniak is not operable to store an aggregation of 
data values representing an aggregation of at least one of the plurality of 
conceptual entities, but instead stores only arbitrary identifiers (i.e. not actual data 
values ) given to the various other entities, for "space efficiency" (see Krychniak 
column 1 lines 25 to 47). In other words, as the field table only holds kev values, 
a user wishing to retrieve data values from the database is still required to perform 
computationally expensive join operations in order to retrieve the subject data. 
Therefore the disclosure of Krychniak cannot provide the advantage of the 
claimed invention, namely the more efficient retrieval of data values from the 
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database. Applicant docs not understand where there is descriptive support in 
Krychniak that teaches the fact table being arranged to store an aggregation of 
data values created responsive to determining that the performance of the 
database could be improved (expressly required by the method steps of the 
presently claimed invention). 
Further, and with regards to Prabhakaran, the Applicant is puzzled as to how the cited 
passages "explicitly teach" of accessing the database to determine the read/write ratio of the 
plurality of data values and comparing the determined read/write ratio with other ratios. 

Again, the Applicant lias carried out a detailed review of the cited passage of 
Prabhakaran but could not find any teaching of accessing the database to determine read/write 
ratios (let alone in the context of comparing the determined rati o against a critical ratio to decide 
whether or not to create an additional table). 

In complete contrast, the cited passages (of Prabhakaran ) teach of 
setting a read/write ratio (see column 5 lines 51 to 55) and 
initiating a plurality of operations (capable of achieving the set 
ratio) to the database storage system to test whether the system is 
capable of "handling" the §et read/write ratio. This may involve 
inspecting the number of read and write operations attempted by 
the database storage system, the number of operations completed, 
etc (see column 7, lines 59 to 66). Furthermore, the Applicant 
could not locate any explicit teaching of "comparing" a read/write 
ratio to another ratio. To reiterate: 

Prabhakaran shows no teaching of "comparing" one read/write 

ratio to another read/write ratio. 
H. Turning to the second point. Applicants note that the ground for obviousness can only 
be established by combining or modifying the teachings of the prior art to produce the claimed 
invention where there is some teaching, suggestion, or motivation to do so . Applicants submit 
that there is no such teaching, suggestion or motivation present in the cited references which 
would work for engineering compatibility without undue experimentation. Substantial redesign 
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and reconfiguration would be required to enable any such combination suggested by the 
Examiner . 

Krychniak relates to a system/method for improving the performance of a 
database by choosing the most efficient Query structure depending on the actual 
attributes to be queried. For example, the system may choose to query on a "key 
value" rather than an attribute value if the number of key values which appear in 
the query is less than a predetermined threshold. Krychniak does not teach or 
suggest of creating an additional entity table responsive to determining that an 
average read/write ratio of the database is greater than a critical read/write ratio. 
In fact, in no way whatsoever does Krychniak suggest modifying the database 
structure (i.e. defining an additional entity table storing an aggregation of a 
plurality of data values representing an aggregation of at least one of the plurality 
of conceptual entities). Note Applicant's amended claims 22 (iia) ? (iib) and 27 
(iia) and (iib). 

In and of itself, Applicants submit that the mere fact that Krychniak fails to disclose 
creating an additional entity table (or, in fact, modifying the pre-existing database structure in 
any manner) to improve performance provides sufficient basis for the Examiner to withdraw his 
obviousness objection. 

Nonetheless, for completeness, assuming that Krychniak d id teach of creating an 
additional entity table, Applicants submit that there would have been insufficient motivation for 
the relevant skilled person to have looked to Prabhakaran ei al and Tenorio given that: 

(a) neither reference suggests of utilising read/write ratios (including a critical read/write 
ratio) in any manner to establish whether or not to create additional entity tables for 
improving the performance of the database; and 

(b) both Prabhakaran e( al and Tenorio are both directed to overcoming entirely 
unrelated problems: 

Tenorio is solving the problem of large databases structures being 
difficult to search due to a lack of indexing (see Tenorio Column 4 
lines 21 bridging to Column 5 line 20); and Prabhakaran et al is 
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addressing problems with conventional load testing tools being 
unable to directly measure the performance of an enterprise storage 
system (see Prabhakaran Column 1 line 64 bridging to Column 2 
line 18). 

Arguably, both Tenorio and the presently claimed invention both teach of a read/write 
ratio calculated by determining a read time and write time difference between a first 
implementation and second implementation* However* according to Tenorio the 
read/write ratio is not utilised to determine whether or not to alter the fields or schema of 
the database for improving efficiency (i.e. defining an additional entity table storing an 
aggregation of data values distributed amongst at least one set of linked entities), but 
instead is merely used to determine whether or not to index the database. 

See, for example, Tenorio Column 19 lines 53 to 55 which explicitly states: 
"the total read times and total write times with and without 
indexing are evaluated to determine whether the fields associated 
with the selected feature should be indexed". 



As Tenorio does not teach or suggest of modifying the fields or schema of the 
database to improve efficiency, there would be no reason for a person skilled in 
the art to look to Tenorio for determining a "critical read/write ratio". 
Then note Tenario at column 20 at claim 1 at the last clause (lines 29 - 3 1): 

- — evaluating the total times required for reading data from 
and writing data to the fields to determine whether the fields 
should he indexed — 
This factor is expressed also in the Tenario Abstract in the last three lines. 
For at least the reasons outlined above, Applicant submits that the claims are non-obvious 
in view of Krychniak when combined with both Prabhakaran et al and Tenorio and accordingly, 
Applicants request that the Examiner's objection be withdrawn. 

It should be further indicated that when the Examiner combines references such as 
Krychniak, Prabhakaran and Tenorio, the combination must present a fully workable apparatus 
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of system which can be operable without undue experimentation. Thus the Examiner should 
recognize the substantial engineering redesign, reconfiguration, experimentation and testing 
required to integrate the features of Krychniak. Prabharan, and Tenario into a workable system to 
integrate these references to provide the equivalent features of Applicant' s system, and the 
cited references never even teach the feature of "comparing" one read/write ratio with another 
critical read/write ratio, as provided by Applicants in determining whether to alter the fields of 
the database format. 

In regard to the newly amended claims it might be worthwhile to indicate that language 
has been inserted in claims 22 and 27 to specifically define how the first and the second 
implementations differ. 

The first implementation comprises at least one set of linked entities — while the 
second implementation comprises an aggregation of all data value stored in the at 
least one set of linked entities. 

In this regard according to Tenono, — the critical read/write ratio is not used to 
determine whether or not to alter the field or schema of the database to improve efficiency, that 
is to say, define an additional entity table storing an aggregation of data values distributed 
amongst at least one set of the linked entites ™ but Tenorio instead is merely using its critical 
read/write ratio to determine whether or not to index the database. 

Applicants have argued there is no explicit teaching of confirming ratios in Prabhakaran 
Examiner argued that Prabhakaran has drawing references in Fig, 3 at 320 and 330 that show 
Prabhakaran is "trying" to "achieve'' a comparison. There is no clear teaching here. 

Item 330 of Prabhakaran Fig. 3 only involves generating Read and Write Operations to 
the database to correspond to a "desired" read/write ratio. 

Then further, Examiner states that the "computing" language is such because Tenorio 
also teaches a comparison of ratios (column 1 7 lines 45 - 59 and Fig. 6). But Tenorio has a 
different purpose — to index a database. 

In regard to Applicant's argument that there is no suggestion or motivation to combine 
the references where Examiner maintains that Krychniak does "suggest" a means to modify the 
database structure. 
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Examiner argues Krychniak does "suggest" a need to modify the database structure 
because Krychniak shows this by disclosing that one should consider indexing using a fact table 
Krychniak at column 1 lines 6-8 states: 

The present invention reLates to querying data in a database and more specifically 
to a method of selecting appropriate query parameters to efficiently perform a 
query. 

This querying data also does not match Applicant's use of average and critical 
read/write ratios to modify or not modify the database schema. 
And particularly - quoting Krychniak column 2 lines 29 -36: 

Databases might be optimized for example by indexing the fact table by key value 
in each dimension. The appropriate fact data to include in the resultant data set 
can then be very quickly found by scanning through the entries for each key in the 
index, as the indexes associated with a particular key are arranged consecutively. 
If such an index based optimizing scheme is used by the database, the following 
type of query will often be more advantageous to use, even when querying on key 
values: SELECT factkeyl, factkey2, factkey3„ factml, fact.2 FROM fact, dim 
1, dim2, dim3. 

But note Krychniak' s teaching is limited to "indexing" a fact table by key value for 
database optimization. 

Applicants quite differently based their modification of the database according to the 
values of an average read/write ratio compared to a critical read/write ratio. 

Applicants would say that this is speculation as to what might happen or what could be. 
And these possibilities are not a true motivation for combining features. 

So with the statements by the Examiner as to certain "possibilities" Applicants do not feel 
that it is sufficient justification for the combination of references on the basis that certain 
possibilities could occur which "might improve" the operation of a given system. 
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Conclusion 

In this regard Applicants would ask that the Examiner consider the claims as a whole in 
their entirety and then subsequently provide a Notice of Allowance therefor. 
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